A storage system is a computer that provides storage service relating to the organization of information on writable persistent storage devices, such as memories, tapes or disks. The storage system may be deployed within a storage area network (SAN) or a network attached storage (NAS) environment. When used within a NAS environment, the storage system may be embodied as a file server including an operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on, e.g., the disks. Each “on-disk” file may be implemented as a is set of data structures, e.g., disk blocks, configured to store information, such as the actual data for the file. A directory, on the other hand, may be implemented as a specially formatted file in which information about other files and directories are stored.
The file server, or filer, may be further configured to operate according to a client/server model of information delivery to thereby allow many client systems (clients) to access shared resources, such as files, stored on the filer. Sharing of files is a hallmark of a NAS system, which is enabled because of semantic level of access to files and file systems. Storage of information on a NAS system is typically deployed over a computer network comprising a geographically distributed collection of interconnected communication links, such as Ethernet, that allow clients to remotely access the information (files) on the filer. The clients typically communicate with the filer by exchanging discrete frames or packets of data according to pre-defined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP).
In the client/server model, the client may comprise an application executing on a computer that “connects” to the filer over a computer network, such as a point-to-point link, shared local area network, wide area network or virtual private network implemented over a public network, such as the Internet. An example of an application running on a client is the Microsoft® Exchange application available from Microsoft Corporation, Redmond, Wash. Microsoft Exchange is a messaging and collaboration software product that provides a variety of applications for group interaction using networked computer systems. An Exchange application can run on a variety of operating systems including, for example, the Microsoft Windows® NT™ or Microsoft Windows 2000 operating system. A known file system designed for use with the NT or Windows 2000 operating system is the NT file system (NTFS).
In general, NAS systems utilize file-based protocols to access data stored on the filer. Each NAS client may therefore request the services of the filer by issuing file system protocol messages (in the form of packets) to the file system over the network. By supporting a plurality of file system protocols, such as the conventional Common Internet File System (CIFS), the Network File System (NFS) and the Direct Access File System (DAFS) protocols, the utility of the filer may be enhanced for networking clients.
A SAN is a high-speed network that enables establishment of direct connections between a storage system, such as an application server, and its storage devices. The SAN may thus be viewed as an extension to a storage bus and, as such, an operating system of the storage system enables access to stored information using block-based access protocols over the “extended bus”. In this context, the extended bus is typically embodied as Fibre Channel (FC) or Ethernet media (i.e., network) adapted to operate with block access protocols, such as Small Computer Systems Interface (SCSI) protocol encapsulation over FC (FCP) or TCP/IP/Ethernet (iSCSI).
SCSI is a peripheral input/output (I/O) interface with a standard, device independent protocol that allows different peripheral storage devices, such as disks, to attach to the storage system. These storage devices may be locally attached to the storage system or, in the case of a SAN environment, attached via a network. In SCSI terminology, clients operating in a SAN environment are initiators that initiate requests and commands for data stored on the storage devices. The storage system is a target configured to respond to the requests issued by the initiators in accordance with a request/response protocol. The SAN clients typically identify and address the stored information in the form of blocks or disks by logical unit numbers (“luns”).
There are differences in the interpretation of data that is exchanged between a client and storage system using block access protocols compared to file access protocols. A block access protocol, such as the SCSI protocol, “assumes” that the storage device is composed of a sequence of blocks, each containing either data or available space for storing data. Requests for retrieving (reading) or storing (writing) data include references for block numbers and data lengths. As a result, an application issuing a SCSI request (i.e., a SCSI requestor or initiator) must have knowledge of the metadata “disk semantic” mapping between the desired application data and the physical location of that data on the is storage device. These disk semantics, which include SCSI geometry information pertaining to partitioning of the disk(s) storing the application data, are operating system specific and may be organized as either a partition table (for a Windows client) or a label (for a Solaris™/Unix® client).
In contrast, file access protocols assume that the server (filer) has a file system on which application data is stored. The file system generally refers to structuring of data and metadata on storage devices, such as disks, which permits reading/writing of data on those disks. The file system also includes mechanisms for performing these operations. While different file access protocols provide different semantics, each protocol fundamentally provides access to file system constructs, such as directories and files. The filer is responsible for mapping the files to its storage system.
Nevertheless, it may be desirable for a client application to access data (such as a file) on a storage system as a lun using a block access protocol. Examples of such data include a virtual logical disk (VLD), application file data and a database. Broadly stated, the VLD comprises NTFS file system and Exchange application data organized as a “container”. The container is stored as a file on a file system and is “understandable” by a VLD disk driver constructed on a Windows 2000 client. The VLD driver functions as a translator that simulates a disk on the client by translating SCSI requests on the client into NFS requests to access the file (container) on a server, such as a filer. Simulation is performed using a 64 kilobyte (KB) header affixed to the file that contains access control information, along with information regarding properties of a disk storing the VLD file.
DDAFS is a disk driver constructed on a Solaris client that simulates a disk to the client, but that performs input/output operations using the DAFS protocol when accessing data stored as a file on the filer. Whereas the VLD file has a 64 k header, the DDAFS implementation of disk driver simulation comprises solely application data contents of the file. Simulations involving partition tables are then performed on the Solaris client. In contrast, a database, such as an Oracle® database, generally operates as a “raw” disk. From a Windows or Solaris client perspective, a raw disk is a disk that has a label, but no formatted partitions within the disk. For an application to access the database as a file, the label is eliminated because the disk semantics have no meaning within a “file view” of the data.
Notably, with respect to the client, the application data is the desired content of these files. All of the semantic information needed for the disk driver layer support resides “outside” of the application data. In other words, the application data is a contiguous section of data having similar format and usability, but surrounded by different semantics. In the VLD case, the semantics are embodied within a 64 k header, whereas for a raw disk, the application data is contained in a single large partition with a prepended partition table. In the DDAFS case, the application data is embodied as a single file with no headers, but which has a prepended label for the Solaris client.
Therefore, it is desirable to access a VLD or DDAFS file over block-based (SAN) protocols, such as FCP and iSCSI. In addition, it is desirable to access a database as either a file over file-based (NAS) protocols or as a lun over SAN protocols. The present invention is directed to a technique that enables a client to access application data as a lun, a file or other type of storage entity.